Компания VMware, начиная с 9 августа, запустила интересную промо-акцию, направленную на стимулирование приобретения продуктов VMware vSphere и их апгрейд на более продвинутые версии.
Наглядная суть акции:
Что это значит:
1. Приобретая лицензии VMware vSphere (не Essentials и Essentials Plus) или делая апгрейд можно, по крайней мере, бесплатно получить 15 лицензий на VMware vCenter CapacityIQ - средство учета и прогнозирования мощностей виртуальной инфраструктуры (лицензируется по виртуальным машинам).
2. Приобретая лицензии на издания VMware vSphere 4 Enterprise Plus или делая апгрейд на него с любого издания, можно получить лицензии на 50 одновременно запущенных виртуальных ПК VMware View 4.5 Premier Add-on. При этом цена апгрейда с Enterprise до Enterprise Plus составляет всего $495 за физический процессор (это валидно с 1 сентября). Ну и CapacityIQ на 15 ВМ тоже при этом дарят. Ну и Novell SUSE Linux Enterprise Server for VMware прикладывают впридачу.
Полный список, участвующих в акции продуктов представлен здесь. За приобретением продуктов обращаться в компанию VMC.
Время акции - с 9 августа 2010 по 15 декабря 2010.
Технология VMware Fault Tolerance позволяет защитить виртуальные машины с помощью кластеров непрерывной доступности, позволяющих в случае отказа хоста с основной виртуальной машиной мгновенно переключиться на ее "теневую" работющую копию на другом сервере ESX. Однако эта технология имеет существенные ограничения, приведенные ниже. Таги: VMware, Fault Tolerance, FT, vSphere, ESX, DRS, DPM, HA, Enterprise
Давно что-то не было сравнений гипервизоров. Недавно блоггеры портала vmguru.nl подготовили очередной открытый документ, где по нескольким параметрам сравнили технические возможности платформ виртуализации VMware vSphere, Microsoft Hyper-V и Citrix XenServer.
Номинально - Citrix XenServer 5.6 уже вовсе не так плох, каким он был где-то года полтора назад, Hyper-V подтягивается тоже (ждем SP1 для Windows 2008 R2). Вообще, я удивляюсь, кому приходит в голову писать такие сравнения - только напишешь, тут бац - выходит новая версия какой-нибудь из платформ, и все надо переписывать заново. Кроме того, учесть все параметры невозможно, например, в данном документе есть максимум половина всех возможностей, которые есть у VMware. А еще в таких документах интереснее всего было бы видеть категории, где напротив всех гипервизоров стоят красные крестики. Секрет таких категорий прост - берешь суперсекретную VMware Roadmap и вписываешь планируемые возможности в обобщенном виде.
Как вы знаете, в VMware vSphere 4.1 механизм VMware DRS, осуществляющий балансировку нагрузки на хост-серверы ESX, теперь интегрирован с технологией непрерывной доступности VMware Faut Tolerance.
То есть DRS автоматически распределяет по хост-серверам и FT-машины, однако тут есть небольшой нюанс. В соответствии с рекомендациями Fault Tolerance, число таких машин на хосте должно быть не больше 4-х в целях оптимального быстродействия. Если вы попробуете смигрировать пятую виртуальную машину с включенной технологией FT на хост, вы получите вот такое сообщение:
Host already has the recommended number of 4 Fault Tolerance VMs running on it
То есть DRS не смигрирует и не сделает Initial Placement для FT-машин на хосты VMware ESX, где уже работают 4 таких ВМ. Однако, есть возможность увеличить это количество. Для этого необходимо в расширенных настройках (Advanced Settings) кластера VMware HA/DRS добавить параметр:
das.maxftvmsperhost
со значением, например, 6. Если вы поставите значение 0, то VMware DRS будет полностью игнорировать данное требование к числу FT-машин на хост.
Администраторы, работающие с платформой виртуализации VMware vSphere, часто встречаются с различного рода акронимами в интерфейсе vSphere Client (например, vmx, VPXD или VPXA).
Duncan Epping в своей заметке разъяснил происхождение некоторых терминов (комментарии также почитать интересно):
ESX = Elastic Sky X
GSX = Ground Storm X also some times referred to as Ground Swell X
Пакет продуктов VMware vSphere 4.1 вышел уже две недели назад, особенных ошибок в новой сборке выявлено не было, а значит настало время обновлять свои хосты VMware ESX 4.0 Update 1 или Update 2 на VMware ESX 4.1.
Прежде всего, вам надо пойти по этой ссылке на сайт VMware и скачать два пакета для проведения обновления (у вас должен быть действующий контракт на подписку SnS):
Далее нужно скопировать эти файлы в сервисную консоль сервера VMware ESX, например, с помощью бесплатной утилиты Veeam FastSCP. После этого в Service Console VMware ESX 4.0 выполняем следующие действия:
1. Переводим хост в Maintenance Mode. Это можно сделать либо из vSphere Client, либо командой:
# vimsh -n -e /hostsvc/maintenance_mode_enter
2. Выполняем команду в директории с файлами обновления:
В частности интересна формула, отражающая требования к пропускной способности FT-канала между серверами VMware ESX:
FT logging bandwidth = 1 Mbit/s + 1.2 * (average disk read throughput
[Mbits/s] + average network receives [Mbits/s])
Также интересно описание работы FT-протокола, результаты экспериментального тестирования и анализ различных подходов к непрерывной доступности виртуальных машин, в том числе с раздельным хранилищем для виртуальных дисков основной и резервной ВМ (здесь, кстати, интересна конфигурация FT + StarWind - как средство отказоустойчивости на уровне хранилищ + серверов).
Как вы знаете, в новой версии платформы виртуализации VMware vSphere 4.1 появилась замечательная возможность создавать виртуальные машины, у которых один виртуальный процессор (vCPU) может иметь несколько ядер (Multicore vCPU). Более ранние версии VMware ESX умели представлять только одно ядро на виртуальный vCPU машины, а сама возможность многоядерности процессоров ВМ была экспериментальной.
Как известно, многие возможности VMware vSphere приходят из настольных платформ, после того, как пройдут "обкатку" пользователями на некритичных виртуальных окружениях. Например, тонкие диски или технология TPS, которая называлась просто Page Sharing, насколько я помню, пришли из VMware Workstation.
Теперь в VMware ESX 4.1 можно создавать несколько виртуальных ядер, правда не так элегантно как это реализовано в VMware Workstation 7:
Операционная система в этом случае будет видеть виртуальные ядра vCPU виртуальной машины как отдельные логические процессоры.
Чтобы сделать это в VMware ESX 4.1, нужно открыть свойства виртуальной машины, перейти на вкладку Options и выбрать категорию General в списке Advanced options. Затем нужно нажать кнопку Configuration Parameters, которая позволит изменить vmx-файл конфигурации ВМ с помощью построчного добавления параметров и их значений.
Нужно добавить вот такую строчку в качестве параметра:
cpuid.coresPerSocket
В качестве значения можно задавать число ядер на виртуальные vCPU нашей машины. При этом число ядер должно быть степенью числа 2 (то есть 1, 2, 4 или 8 ядер - про большее не упоминается в документации).
Какие требования предъявляются к виртуальным машинам с несколькими ядрами на одном vCPU:
Поддерживается в производственной среде только для VMware ESX 4.1
Virtual Machine hardware должно быть версии 7 или выше
Чтобы настроить этот параметр, нужно предварительно выключить виртуальную машину
Опция CPU hot Add/Remove будет отключена
Почему так далеко запрятана эта возможность? Ответ прост - чтобы не баловались. Потому как нужна она только в случаях, когда особенно требуется экономия на лицензировании при необходимости наращивания производительности виртуальной машины (как раз за счет числа виртуальных ядер). То есть, если ОС или приложения лицензируются на процессор (в данном случае виртуальный), то нашпиговывание его виртуальными ядрами не увеличит стоимость необходимых лицензий, но увеличит производительность ВМ.
Однако, здесь есть одно но. Необходимо внимательно читать EULA к своему развертываемому ПО в виртуальных машинах, где определены понятия сокета, процессора и ядра, в том числе, иногда и для виртуальных сред. Очень вероятно, что такой финт с наращиванием ядер будет нарушать условия EULA.
Как уже много писали об этом ранее, одной из проблем механизма отказоустойчивости VMware HA является его потенциальное не срабатывание в окружениях, где одновременно отказывает более 4-х хостов в кластере (например, на уровне блейд-корзины), когда не доступны все 5 primary-узлов. В этом случае есть риск, что виртуальные машины не перезапустятся на оставшихся хост-северах.
В VMware vSphere 4.1 появилась возможность явным образом указать, какие узлы в кластере VMware HA будут являться Primary:
Можно использовать в качестве разделителя пробел или запятую.
Эти настройки необходимо указывать в расширенных свойствах кластера VMware HA (Advanced Settings). Обращаю внимание, что хоть эти настройки и не являются experimental, они являются неподдерживаемыми со стороны VMware и не рекомендуются к использованию в промышленной среде. Кстати, скоро кластер VMware HA будет переживать сколько угодно отказов хостов ESX / ESXi.
Компания VMware выпустила очень интересный и рекомендуемый к прочтению администраторами VMware vSphere документ "Understanding Memory Resource Management in VMware ESX 4.1". В данном документе описывается, как гипервизор ESX / ESXi обращается с оперативной памятью хост-сервера виртуализации при исполнении виртуальных машин.
Подобный документ существовал у VMware и ранее, но теперь в нем добавилось описание техники Memory Compression, которая позволяет существенно экономить физическую память хост-сервера за счет сжатия страниц, которые должны были попасть в своп.
Также в этом документе указано, как можно управлять кэшем (Compression Cache), где лежат эти сжатые страницы памяти для виртуальной машины:
Известный поставщик решения для управления виртуальной инфраструктурой VMware, компания Veeam, выпустила новую версию своего продукта Veeam Monitor 5.0, позволяющего осуществлять комплексный мониторинг серверов ESX/ESXi.
Информация об использовании электропитания хостов ESX/ESXi
Информация о технике Memory Compression
Скачать Veeam Monitor 5.0 можно по этой ссылке. Купить эту офигенную штучку для своей VMware vSphere 4.1 можно в компании VMC, золотом партнере Veeam Software.
Компания VMware официально объявила о выпуске новой версии платформы виртуализации VMware vSphere 4.1 13 июля 2010 года. Это существенное обновление компонентов пакета, включая серверы виртуализации VMware ESX 4.1 и средство управления хост-серверами и виртуальными машинами VMware vCenter 4.1.
Итак, вы уже ознакомились с новыми возможностями платформы виртуализации VMware vSphere 4.1, пора понять, какие же изменения произошли в структуре продукта: то есть ценах и изданиях.
Изменения в отдельных изданиях VMware vSphere 4.1.
Если говорить об отдельной покупке изданий vSphere 4.1 - то они по прежнему лицензируются на CPU хост-серверов ESX или ESXi. Новые возможности, в основном, добавились в VMware vSphere Enterprise Plus, зато технология VMware VMotion впервые вошла в издание Standard.
Вот сравнительная таблица изданий VMware vSphere 4.1:
Издания VMware vSphere 4.1
Standard
Advanced
Enterprise
Enterprise Plus
Компоненты платформы
Физическая оперативная память хост-сервера ESX/ESXi 4.1
256 ГБ
256 ГБ
256 ГБ
Нет ограничений
Число ядер на физический процессор
6
12
6
12
Способ лицензирования
На 1 CPU
На 1 CPU
На 1 CPU
На 1 CPU
Возможности централизованного управления хост-серверами и виртуальными машинами
VMware vCenter (приобретается отдельно)
vCenter Foundation (не более 3 хост-серверов)
vCenter Standard (без ограничений)
vCenter Foundation (не более 3 хост-серверов)
vCenter Standard (без ограничений)
vCenter Foundation (не более 3 хост-серверов)
vCenter Standard (без ограничений)
vCenter Foundation (не более 3 хост-серверов)
vCenter Standard (без ограничений)
Возможности платформы
Thin Provisioning - возможность использования для виртуальных машин дисков, растущих по мере наполнения данными
Update Manager - средство централизованного обновления хостов ESX/ESXi и виртуальных машин
Data Recovery - средство резервного копирования и восстановления виртуальных машин и их файлов
Приобретается отдельно для этого издания
High Availability - средство отказоустойчивости виртуальных машин, позволяющее в случае отказа физического хост-сервера автоматически перезапустить его виртуальные машины с общего хранилища
vMotion - возможность перемещения виртуальной машины между физическими серверами без прерывания ее работы и сетевых соединений
vStorage APIs for Data Protection - интерфейс, позволяющий применять встроенные и сторонние средства для защиты данных виртуальных машин, в т.ч. резервное копирование Veeam Backup and Replication
Virtual Serial Port Concentrator - виртуальное устройство для управления виртуальными машинами через последовательный порт
Hot Add - возможность горячего добавления и удаления устройств виртуальной машины во время ее работы (процессоров и памяти)
vShield Zones - средство обеспечения сетевой безопасности виртуальной инфраструктуры, включая контроль различных типов траффика
Fault Tolerance - средство непрерывной доступности виртуальных машин, позволяющее поддерживать резервную работающую копию виртуальной машины на другом сервере, которая мгновенно переключает на себя нагрузку в случае отказа основной машины
vStorage APIs for Array Integration (VAAI) - интерфейс, поддерживаемый производителями дисковых массивов, позволяющий передать операции по управлению данными на сторону аппаратного обеспечения, что повышает быстродействие и надежность операций
vStorage APIs for Multipathing - интерфейс для управления доступом по нескольким путям в SAN, используемый приложениями сторонних производителей
Storage vMotion - возможность динамического перемещения хранилища виртуальной машины между массивами без прерывания работы приложений в гостевой ОС
Distributed Resources Scheduler (DRS), Distributed Power Management (DPM) - средства балансировки нагрузки на хост-серверы за счет динамических миграций VMotion, а также средства экономии электропитания за счет перевод простаивающих серверов в режим Standby
Storage I/O Control - технология приоритизации доступа виртуальных машин к хранилищам, позволяющая гарантировать уровни обслуживания для приложений по вводу-выводу
Network I/O Control - технология приоритизации траффика различного типа в пределах сетевых адаптеров
Distributed Switch - средство централизованного управления и конфигурации сетевого взаимодействия хостов VMware ESX / ESXi (виртуальный распределенный коммутатор)
VMware vSphere Standard дорожает на 20% и теперь вместо $795 за процессор стоит $995 за процессор.
Торопитесь размещать заказы на этой и следующей неделе в компании VMC.
Изменения в структуре пакетов ПО VMware vSphere 4.1.
VMware vSphere 4.1 может поставляться пакетам типа "все-в-одном", которые представляют собой готовые к развертыванию издания платформы вместе со средством управления VMware vCenter. Называются они VMware vSphere Essentials / Essentials Plus и VMware vSphere Acceleration Kits. Стоят эти пакеты значительно дешевле закупки лицензий по изданиям, но могут быть куплены только один раз для площадки заказчика.
Основные изменения, которые произвошли в пакетах:
Технология VMware VMotion появилась в составе пакета VMware vSphere Essentials Plus
VMware Essentials окончательно подешевел (на 50%) до стоимости $495
VMware Essentials Plus подорожал на 15% с 26 июля с $2,995 до $3,495 (без учета стоимости поддержки)
Остальные позиции подорожали на 10% с 26 июля
Вот сравнительная таблица пакетов ПО VMware vSphere 4.1:
Пакеты ПО VMware vSphere 4.1
Essentials
Essentials Plus
Advanced Acceleration Kit
Midsize Acceleration Kit
Enterprise Plus
Acceleration Kit
Структура пакета
Стандартное издание (аналог отдельной покупки лицензий)
Нет аналога
Нет аналога
Advanced
Enterprise
Enterprise Plus
Число лицензий на CPU физических хост-серверов
6
6
6
6
8
Использование лицензий на CPU
Только хост-серверы с не более 2 CPU в каждом. Не более 3-х серверов в сумме.
Только хост-серверы с не более 2 CPU в каждом. Не более 3-х серверов в сумме.
Нет ограничений
Нет ограничений
Нет ограничений
Возможность обновления
Essentials Plus и Advanced Acceleration Kit
Advanced Acceleration Kit
Midsize Acceleration Kit и Enterprise Plus Acceleration Kit
Enterprise Plus Acceleration Kit
Нет
Компоненты платформы
Физическая оперативная память хост-сервера ESX/ESXi 4.1
256 ГБ
256 ГБ
256 ГБ
256 ГБ
Нет ограничений
Число ядер на физический процессор
6
6
12
6
12
Способ лицензирования
Только весь пакет
Только весь пакет
Только весь пакет
Только весь пакет
Только весь пакет
Возможности централизованного управления хост-серверами и виртуальными машинами
VMware vCenter (включен в состав пакета)
vCenter Essentials (не более 3 хост-серверов, не более 2 CPU в каждом)
vCenter Essentials (не более 3 хост-серверов, не более 2 CPU в каждом)
vCenter Foundation (не более 3 хост-серверов)
vCenter Standard (без ограничений)
vCenter Standard (без ограничений)
Возможно ли отдельное обновление vCenter?
Нет. Только пакет целиком
Нет. Только пакет целиком
Да. На vCenter Standard
Не требуется
Не требуется
Возможности платформы
Thin Provisioning - возможность использования для виртуальных машин дисков, растущих по мере наполнения данными
Update Manager - средство централизованного обновления хостов ESX/ESXi и виртуальных машин
Data Recovery - средство резервного копирования и восстановления виртуальных машин и их файлов
High Availability - средство отказоустойчивости виртуальных машин, позволяющее в случае отказа физического хост-сервера автоматически перезапустить его виртуальные машины с общего хранилища
vMotion - возможность перемещения виртуальной машины между физическими серверами без прерывания ее работы и сетевых соединений
vStorage APIs for Data Protection - интерфейс, позволяющий применять встроенные и сторонние средства для защиты данных виртуальных машин, в т.ч. резервное копирование Veeam Backup and Replication
Virtual Serial Port Concentrator - виртуальное устройство для управления виртуальными машинами через последовательный порт
Hot Add - возможность горячего добавления и удаления устройств виртуальной машины во время ее работы (процессоров и памяти)
vShield Zones - средство обеспечения сетевой безопасности виртуальной инфраструктуры, включая контроль различных типов траффика
Fault Tolerance - средство непрерывной доступности виртуальных машин, позволяющее поддерживать резервную работающую копию виртуальной машины на другом сервере, которая мгновенно переключает на себя нагрузку в случае отказа основной машины
vStorage APIs for Array Integration (VAAI) - интерфейс, поддерживаемый производителями дисковых массивов, позволяющий передать операции по управлению данными на сторону аппаратного обеспечения, что повышает быстродействие и надежность операций
vStorage APIs for Multipathing - интерфейс для управления доступом по нескольким путям в SAN, используемый приложениями сторонних производителей
Storage vMotion - возможность динамического перемещения хранилища виртуальной машины между массивами без прерывания работы приложений в гостевой ОС
Distributed Resources Scheduler (DRS), Distributed Power Management (DPM) - средства балансировки нагрузки на хост-серверы за счет динамических миграций VMotion, а также средства экономии электропитания за счет перевод простаивающих серверов в режим Standby
Storage I/O Control - технология приоритизации доступа виртуальных машин к хранилищам, позволяющая гарантировать уровни обслуживания для приложений по вводу-выводу
Network I/O Control - технология приоритизации траффика различного типа в пределах сетевых адаптеров
Distributed Switch - средство централизованного управления и конфигурации сетевого взаимодействия хостов VMware ESX / ESXi (виртуальный распределенный коммутатор)
У меня для вас опять эксклюзив. Как вы уже, наверное, знаете, вчера компания VMware анонсировала новую версию своей платформы виртуализации VMware vSphere 4.1. Мало того, ESX 4.1, ESXi 4.1 и vCenter 4.1 уже можно скачать с сайта VMware.
Прямо к выпуску VMware vSphere 4.1, чтобы вы не утруждали себя чтением англоязычной документации, я подготовил технический документ с описанием всех новых возможностей платформы, который можно свободно скачать с сайта компании VMC.
В документе описываются все основные технические моменты, включая такие технологии как Storage IO Control (SIOC), Transparent Memory Compression, Load Balanced Teaming, полная поддержка Tech Support Mode в VMware ESXi, новые возможности и максимумы VMware vCenter 4.1 и многое-многое другое. Что немаловажно, в документе есть также секция и про VMware ESXi 4.1, ведь это последняя версия платформы, в которой еще есть ESX - в дальнейшем вся ваша виртуальная инфраструктура уже будет работать на ESXi.
Давно я что-то не писал о своих друзьях из компании Veeam Software, который делают лучшее в мире средство резервного копирования Veeam Backup and Replication (больше здесь и здесь). Как вы знаете они сейчас интенсивно готовят к выпуску Veeam Backup and Replication 5, который будет иметь чудесную (не имеющую аналогов!) технологию SureBackup.
Недавно коллеги из Veeam выпустили открытый документ, где подытожили 7 основных причин, по которым пользователи выбирают именно Veeam Backup, а не всякую второсортную бурду: "7 Reasons to Choose Veeam".
Документ, конечно, маркетинговый, однако маркетинг компании Veeam Software лишь фиксирует то, что так долго и упорно нарабатывалось разработчиками и тестировщиками.
Итак, почему нужно выбирать именно Veeam Backup and Replication:
1. Самый быстрый в мире бэкап виртуальных машин VMware vSphere, позволяющий сузить окно резервного копирования настолько, что оно будет шириной со щель в дифракционной решетке. Именно Veeam использует все преимущества VMware vSphere API for Data Protection, технологию Changed Block Tracking, снапшоты, а также обрабатывает большинство необычных (даже немыслимых) ситуаций, которые могут возникнуть в процессе резервного копирования.
2. Самый простой в мире Restore виртуальных машин и их отдельных файлов. Интерфейс прост настолько, что даже пятилетний ребенок с помощью Drag and Drop вытащит из резервной копии свои файлы (посмотрите на жалкую пародию VMware Data Recovery). При этом Veeam Backup поддерживает не только Windows и Linux системы для восстановления, но и множество остальных nix-систем - и все это в нормальном GUI.
3. Единственные в своем роде возможности репликации, за которые не надо платить (посмотрите на расценки барыг, производящих тяжеловесные СРК). С помощью репликации в Veeam Backup and Replication можно сделать Disaster Recovery конфигурацию виртуальной инфраструктуры между двумя площадками, которая не требует дорогостоящих SAN-устройств и продуктов, а также позволяет защищать отдельные виртуальные машины на томах LUN, а не только весь том VMFS. Конечно же, Veeam Backup полностью поддерживает Microsoft VSS в гостевых ОС.
4. Защита от потерь данных в пределах одного сервера ESX. Если у вас что-то случится с сервером ESX или будут утеряны данные, реплики виртуальных машин на других серверах можно сразу же запустить, а, кроме того, можно автоматизировать любой процесс восстановления с помощью встроенной поддержки PowerShell.
5. Вы можете делать резервные копии и реплики на какие угодно устройства, включая локальные диски серверов VMware ESX. Чуваки из документа навострились делать реплики на локальные диски серверов на случай, если SAN почему-то сломается (все происходит в атоматическом режиме). В этом случае вы сможете мигом восстановить всю виртуальную инфраструктуру.
6. Veeam Backup - это также лучший способ использовать Off-site storage для бэкапов. Используете ленты? Не проблема. Записывайте на них бэкапы Veeam. Кроме того, у Veeam есть встроенные возможности дедупликации хранимых резервных копий (без дополнительной платы, опять-таки, в отличие от барыг) и функции синтетического бэкапа, позволяющие быстрее всего восстанавливать именно последнюю резервную копию.
7. Veeam Backup делает самые красивые ежедневные репорты о том, что все сделано, забэкаплено и защищено, а также имеет централизованную консоль управления серверами резервного копирования. Вам остается только расслабится в эти жаркие дни и думать об отпуске.
Вы уже прониклись всеми волшебными возможностями Veeam Backup and Replication, но все еще не знаете где его купить? Зал хором говорит: "У золотого партнера Veeam - компании VMC!". Там и скидочку дадут и о продукте квалифицированно расскажут.
Как многие знают, недавно компания VMware выпустила обновление продукта VMware vSphere 4.0 Update 2. Среди прочих нововведений есть также улучшения механизма VMware HA для отказоустойчивости серверов VMware ESX. Одно из улучшений - решение проблемы Split Brain в кластере HA, которое заключалось в следующем:
Если у вас есть несколько хостов ESX, подключенных к IP-системе хранения iSCSI / NFS, а для виртуальных машин выставлено действие Leave Powered On для Isolation Responce (по умолчанию), то при отключении хоста от всех сетей (IP Storage и VM Network) процессы VMX, реализующие исполнение виртуальных машин оставались в памяти.
При этом, по истечении срока действия лочек VMware HA, остальные хост-серверы ESX запускали эти виртуальные машины. Когда соединение выпавшего хоста с сетью и хранилищем восстанавливалось - процессы продолжали жить, что приводило к так-называемому "пинг-понгу" виртуальных машин между хостами ESX и всяким глюкам.
Теперь же, начиная с VMware vSphere 4.0 Update 2 эта ситуация решается - хост ESX выключает виртуальную машину и генерирует соответствующее событие в vCenter.
Многие пользователи, применяющие платформу виртуализации VMware vSphere в своей виртуальной инфраструктуре, ищут возможности использования недорогого хранилища для виртуальных машин. В качестве одного из вариантов, для тестового или некритичного производственного окружения, можно рассмотреть организацию NFS-хранилища на базе Windows 2008 Server R2...
Таги: VMware, ESXi, Storage, NFS, ESX, vSphere, Microsoft, Server
На сервере VMware ESX из состава vSphere, если запустить утилиту esxtop и перейти в категорию дисковой подсистемы (кнопка "d"), можно увидеть счетчик CMDS/s.
Что он значит? CMDS/s (Total commands per second) - это общее число SCSI - команд, передаваемых к системе хранения, включая операции ввода-вывода вывода виртуальных машин, а также сервисные команды (например, SCSI reservations). Если говорить о параметре IOPS (Input/Output Operations Per Second) - то это общее число операций ввода-вывода, представляющее сумму:
IOPS = Number of Read commands(READS/s) + Number of Write commands(WRITES/s)
Таким образом, число IOPS должно быть близко к CMDS/s, за исключением случаев, когда сервер VMware ESX активно работает с метаданными тома VMFS (например, создает и удаляет снапшоты).
Компания VMware планирует выпустить новую версию платформы виртуализации VMware vSphere 4.1 не позднее осени этого года (хотя, может быть и раньше). vSphere 4.1 будет обладать множеством новых возможностей, список которых вполне тянет на версию 4.5, а вот, что сегодня известно об улучшениях производительности в новой версии продукта...
Компания VKernel продолжает выпуск бесплатных программных продуктов для виртуализации VMware vSphere. На этот раз это утилита VKernel StorageView, которая позволяет найти "узкие" места в инфраструктуре хранения виртуальных машин. Это обычное десктоп-приложение весом в 6 МБ, которое может быть установлено на рабочей станции администратора и позволяет найти соединения хостов ESX с наибольшими задержками (latency) к томам VMFS или NFS.
Возможности VKernel StorageView:
Топ 5 путей хост / datastore с наибольшей latency
Список виртуальных машин, которые используют эти пути
Скорость обмена трафиком хранения для каждой ВМ в этих путях
Сводная статистика по остальным парам хост / datastore, не вошедшим в топ 5
Как многим известно, компания Veeam Software делает самый лучший продукт для резервного копирования виртуальных машин VMware vSphere / ESX под названием Veeam Backup and Replication. О его возможностях мы уже писали здесь и здесь, а сегодня мы расскажем еще об одной интересной функции - автоматизации задач резервного копирования, репликации и восстановления с помощью Microsoft PowerShell.
Veeam Backup PowerShell Extensions требуют пакетов Windows PowerShell и vSphere PowerCLI, которые позволяют автоматизировать операции по управлению виртуальной инфраструктурой. После их установки на сервере резервного копирования Veeam Baclup and Replication, в меню Tools необходимо выбрать пункт PowerShell.
Далее можно использовать уже готовые командлеты (cmdlets) от Veeam, которые могут делать следующее:
CMDLET
Действие
Add-VBRESX
Add ESX server
Add-VBRESXi
Add ESXi
Add-VBRBackupJob
Create a backup job
Add-VBRReplicaJob
Create a replica job
Add-VBRLinux
Add Linux server
Add-VBRVCenter
Add VirtualCenter server
Add-VBRCopyJob
Add a File Copy job (FastSCP)
Get-VBRJobDestination
Get destination remote or local
Get-VBRJob
Get job list
Get-VBRJobOptions
Get additional backup job settings
Get-VBRReplicaJobs
Get additional replica job settings
Get-VBRJobSchedule
Job Schedule
Get-VBRJobVSSOptions
Backup Consistency VSS
Get-VBRJobRestorePoints
Get restore point
Get-VBRServers
Get hosts list.
Remove-VBRJob
Remove the job
Remove-VBRServer
Remove a server.
Set-VBRESX
Set ESX server options you want to work with to Veeam Backup and FastSCP.
Set-VBRESXi
Set ESXi server options you want t o work with to Veeam Backup and FastSCP.
Set-VBRBackupJob
Edit a backup job
Set-VBRJobOptions
Edit additional backup job settings.
Set-VBRReplicaJob
Set a replica job
Set-VBRJobSchedule
Job Schedule
Set-VBRJobVssOptions
Backup Consistency
Set-VBRLinux
Set the job Linux server options
Set-VBRRestoreVM
Restore VM
Set-VBRRestoreVMFiles
Restoring VM Files: VMX, VMDK, etc
Set-VBRVCenter
Set VirtualCenter server
Start-VBRGuestFileRestore
Start file restore
Start-VBRJob
Start the job
Start-VBRReplicaFailover
Start the replica
Stop-VBRGuestFileRestore
Stop file restore
Stop-VBRJob
Stop the job
Stop-VBRReplicaFailover
Stop the replica
С помощью возможностей PowerShell с Veeam Backup можно сделать очень многое, как, например, сделали в компании "Протек". Используя расширения Veeam Backup PS и PowerCLI / PowerShell, эти ребята разработали систему автоматического тестирования восстановления виртуальных машин из резервных копий (то, что будет реализовано в Veeam Backup and Replication 5 с помощью SureBackup):
Очень много вопросов поступает относительно того, для чего нужны снапшоты виртуальных машин (snapshots) на серверах VMware ESX. По-сути снапшоты - это зло, но иногда они оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем.
Одной из них является неочевидное поведение снапшотов при их удалении (применении к основному диску ВМ). В этом случае вам может понадобиться значительный объем свободного дискового пространства на томе VMFS, особенно когда у вас есть несколько снапшотов. Например, у вас есть виртуальная машина с 3-мя снапшотами следующих размеров:
Вы нажимаете кнопку Delete All в Snapshot Manager в vSphere Client, после чего происходит такая ситуация: Snapshot 3 "склеивается" со Snapshot 2, но при этом сам Snapshot 3 остается на томе VMFS:
При этом занятое дисковое пространство увеличивается на величину Snapshot 3 и составляет 90 ГБ. Далее, то, что получилось в Snapshot 2 (50 ГБ) склеивается со Snapshot 1 (10 ГБ), при этом Snapshot 2 и Snapshot 3 остаются. То есть дисковое пространство, занимаемое файлами виртуальных дисков и снапшотов на томе VMFS увеличивается до 140 ГБ:
Только после всего этого, результирующий Snaphot 1 (60 ГБ - сумма всех снапшотов) применяется к основному файлу виртуального диска VMDK. При этом сам виртуальный диск flat в размере не меняется, поскольку он фиксирован (изменяется только содержимое блоков). И только затем все снапшоты удаляются (все 140 ГБ).
Таким образом, на хранилище VMFS нам понадобится 80 ГБ дополнительного свободного пространства, если мы хотим, чтобы операция прошла успешно (зато потом освободится 60 ГБ от снапшотов).
У пользователей VMware vSphere / ESX иногда возникает ситуация, когда необходимо заглянуть на том VMFS и его содержимое с Windows-машины системного администратора (такое, например, может быть, когда у вас сломался единственный сервер VMware ESX, а содержимое тома VMFS надо скопировать). Кроме того, очень полезным бывает получить доступ к файловой системе диска VMDK, чтобы извлечь из него необходимую информацию, не запуская его в составе виртуальной машины.
Open Source VMFS Driver
В первом случае для просмотра содержимого и копирования данных с тома VMFS версии 3.x (VMware vSphere 4.0 сейчас работает на версии 3.33) нам понадобится Open Source-утилита VMFS Driver от компании Fluid Operations. Она выпускается в виде пакета для Windows или Linux операционной системы (работает на Java) и позволяет монтировать в режиме read only активно работающие тома VMFS, с которых запущены виртуальные машины. По-сути, это не драйвер, а обычное приложение, позволяющее просматривать и копировать содержимое томов VMFS на рабочую станцию администратора. Важно знать, что эта разработка официально не поддерживается со стороны VMware, кроме того у разработчиков для написания утилиты не было спецификаций VMFS. Кстати, сейчас уже поддерживаются thin-диски.
Чтобы начать использовать VMFS Driver наберите в командной строке (у вас должна быть установлена Java):
java -jar fvmfs.jar
VMware Disk Mount
Во втором случае для просмотра содержимого VMDK-диска вам понадобится пакет разработчика Virtual Disk Development Kit, в состав которого входит утилита VMware Disk Mount (vmware-mount.exe или vmware-mount.pl). Эта программа позволяет смонтировать виртуальный диск VMDK в ОС Windows или Linux и просматривать его содержимое как обычного диска, подключенного к компьютеру. Обратите внимание, что последняя версия Virtual Disk Development Kit выпущена 21 мая 2009 года (в тот же день, что и VMware vSphere), а это значит, что поддерживается не только формат виртуальных дисков VMware Workstation, но и VMware ESX 3.x / 4.x (в том числе виртуальные машины vSphere). Пользоваться данной CLI-утилитой очень просто, кроме того, несколько лет назад к ней писали различные GUI-надстройки, которые, вероятно, и сегодня можно использовать.
Пользоваться VMware Disk Mount очень просто - открываете cmd и выполняете команду (где e: - буква монтируемого диска):
Многим пользователям платформы виртуализации VMware vSphere / ESX известен такой механизм оптимизации работы виртуальных машин с оперативной памятью как Memory Ballooning (о нем хорошо написано в документе "Understanding Memory Resource Management in VMware ESX Server"). Если вкратце - то это техника гипервизора по работе с оперативной памятью, которая позволяет запустить на хосте ESX виртуальные машины, совокупная выделенная память которых больше суммарной памяти хоста.
Достигается это за счет использования драйвера vmmemctl.sys, поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС, и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).
Недавно у известного блоггера Дункана Эппинга спросили вот про такой интересный случай. Пользователь запустил команду esxtop на странице с показателями памяти для виртуальных машин и получил вот такой результат:
Собственно, какова ситуация, если смотреть по счетчикам на картинке:
Глобальные статистики:
1393 Free -> Сейчас 1393 МБ физической памяти хоста доступно
High State -> Состояние, в котором считается, что хост не испытывает проблем с памятью
SWAP /MB 146 Cur -> 146 МБ находится в свопе
SWAP /MB 83 Target -> Целевой объем памяти, который должен быть в свопе - 83 МБ
0.00 r/s -> Из свопа ничего не читается
0.00 w/s -> В своп ничего не пишется
Статистики виртуальной машины (обведено красным):
MCTLSZ 1307.27 -> Объем физической памяти гостевой системы, заполненной balloon-драйвером - 1307.27 МБ
MCTLTGT 1307.27 -> Объем физической памяти гостевой системы, который будет сохарнен balloon-драйвером - 1307.27 МБ
SWCUR 146.61 -> В свопе находится 146.61 МБ данных.
SWTGT 83.75 -> Целевой объем памяти, который который должен быть в свопе - 83.75 МБ
С одной стороны хост ESX выглядит типично overcommited, то есть balloon-драйвер раздулся. С другой же стороны, сервер VMware ESX находится в состоянии High State, что означает, что свободно более 6% памяти и проблем с ней нет (кроме того, ничего не пишется и не читается из файла подкачки). Казалось бы, здесь есть некоторое противоречие - если у хоста нет проблем с памятью, то почему balloon до сих пор надут и не сдувается?
Посмотрим на соотношение свободной памяти хоста ESX и размер области, занятой balloon'ом: 1393 МБ и 1307.27 МБ, соответственно. Они приблизительно равны. Это означает, что при сдутии balloon'а гостевая ОС, в которой он был надут, начнет отъедать физическую память хоста ESX (да и еще выгружать своп). Это приведет к тому, что объем доступной памяти хоста ESX упадет и он снова окажется в ситуации, когда необходимо снова надувать balloon.
То есть VMware ESX (и драйвер vmmemctl) не делают резких движений, растут и сдуваются постепенно, делая оглядку на то, какая ситуация может получиться.
Команды esxtop и resxtop теперь показывают информацию и по NAS/NFS-хранилищам
Поддержка технологии Fault Tolerance (FT) для процессоров Intel Xeon 3400, Xeon 5600 и i3/i5 CPU
Поддержка модуля IOMMU для процессоров AMD Opteron 6100 и 4100
Довольно сильно оптимизирована работа со снапшотами (удаление, создание)
Поддержка гостевой ОС Ubuntu 10.04
Исправлена ошибка в реализации round robin в модуле PSP
Исправлена ошибка при доступе по нескольким путям через software iSCSI initiator к некоторым массивам (например, CLARiiON)
Улучшена работа VMware HA с распределенным коммутатором dvSwitch и механизмом Fault Tolerance
Очень много исправлений и мелких улучшений
Сам же VMware vCenter 4.0 Update 2, кроме различных исправлений, содержит возможности конфигурации автоматизированного развертывания следующих гостевых ОС (то, что для Windows называлось Sysprep):
Windows XP Professional SP2 (x64) serviced by Windows Server 2003 SP2
SLES 10 SP3 and 11 (x32/x64 bit)
RHEL 4.8, 5.4 and 5.5 Server Platform (x32/x64 bit)
Debian 5.0, 5.0 R1 and 5.0 R2 (x32/x64 bit)
Продукт VMware vCenter Update Manager 4.0 Update 2 теперь стал быстрее и надежнее работать в низкоскоростных сетях с большими задержками (WAN).
Скачать обновление VMware vSphere 4.0 Update 2 можно по этой ссылке. Напоминаем, что уже известен список возможностей VMware vSphere 4.1, платформы, которая (вероятнее всего) будет представлена на конференции VMworld 2010 в сентябре этого года.
Из всех проблем, создаваемых технологиями виртуализации, настоящей проблемой я считаю только безопасность виртуальной инфраструктуры. Неудивительно, ведь по статистике Gartner, 60% всех развертываемых виртуальных машин к 2012 году будут менее защищенными, чем их физические "коллеги". В итоге - компании достаточно быстро внедряют технологии виртуализации, но очень мало уделяют аспектам безопасности виртуальных машин, хост-серверов и средств управления.
На VMware KB TV есть несколько хороших видео, раскрывающих подробности установки пакета VMware Tools в гостевых ОС Linux виртуальных машин VMware vSphere.
Если ваш дистрибутив rpm-based, можно воспользоваться KB 1018392 или посмотреть процедуру установки VMware Tools для Linux на видео ниже:
Если же ваш Linux-дистрибутив не поддерживает rpm-пакеты, для установки VMware Tools можно воспользоваться KB 1018414 или посмотреть, как это делается:
Общая информация об установке VMware Tools приведена в KB 340 и KB 1014294.
Таги: VMware, Tools, vSphere, ESX, Linux, Обучение
Компания VMware объявила победителей в программе VMware vExpert 2010. Это награда, присуждаемая за высокий вклад в развитие сообщества виртуализации, а также существенное участие в продвижении продуктов и технологий VMware.
Среди профессионалов, получившую данную награду можно отметить таких известных в сообществе виртуализации людей как Mike Laverick, Eric Sloof, Vladan Seget, Tom Howarth и многих-многих других блоггеров и евангелистов в сфере виртуализации, которых вы все хорошо знаете.
Рад сообщить, что среди этих людей второй год подряд остаюсь и я, получая награду VMware vExpert 2010. Большое спасибо компании VMware, менеджеру программы Джону Троеру (John Troyer), а также всем тем, кто номинировал меня на этот статус.
На будущий год у меня в планах становление и продвижение в России консалтинговых сервисов в сфере виртуализации (пока об этом мало кто знает - что это вообще такое), больший акцент на автоматизацию и оптимизацию уже существующих инфраструктур (здесь тоже пока дыра), а также организация "облаков" с помощью продуктов VMware (не только vSphere и View). Все это мы будем делать вместе с вами, дорогие коллеги!